Comprehensive system for product management

ABSTRACT

A comprehensive product management system for a product is provided. The system ( 10 ) includes discrete processes for planning ( 1000 ), engineering ( 2000 ), testing ( 3000 ), producing ( 4000 ), selling ( 6000 ), using ( 8000 ), and servicing ( 10000 ) a product comprising one or more components. It also includes a comprehensive relational database ( 30 ) containing information about the product, performance, sales, consumers, and markets, and system tools ( 20 ) for operating on the discrete processes.

REFERENCE TO RELATED APPLICATION

This application claims the benefit of U.S. Patent Application No.60/595,148, filed Jun. 9, 2005, the entire disclosure of which isincorporated by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention relates to methods for managing a product through itsentire life span, from its design, engineering and manufacture, throughits sale, servicing, and de-commissioning.

2. Description of the Related Art

Every product, whether an object, a machine, or service, andparticularly a product used in the home, has a definable life spanstretching from its origin as an abstract idea to the end of itsusefulness. Networking technologies make it possible to systematizeprocesses associated with transforming a product from an idea to auseful embodiment, using, upgrading and servicing that product duringits life and decommissioning the product at the end of its useful life.

In a world of increasing complexity and speed, there is a need toprovide more convenience, increased simplicity, and less cost in thedelivery of products in the use, upgrading servicing and decommissioningof those products.

SUMMARY OF THE INVENTION

A comprehensive product management system (10) includes discreteprocesses for planning (1000), engineering (2000), testing (3000),producing (4000), selling (6000), using (8000), and servicing (10000) aproduct comprising one or more components. Also provided is acomprehensive relational database (30) containing information about theproduct, including performance, sales, consumers, and markets. Systemtools (20) are provided for operating on the discrete processes. Anyprocess automatically interacts with the comprehensive database, andselectively interacts with the system tools.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings:

FIGS. 1 and 1A are flow charts illustrating a comprehensive system formanaging a product during its life according to the invention.

FIG. 2 is a flow chart showing a product planning process of thecomprehensive system of FIG. 1.

FIG. 3 is a flow chart showing a product engineering process of thecomprehensive system of FIG. 1.

FIG. 4 is a flow chart showing a product and concept testing process ofthe comprehensive system of FIG. 1.

FIG. 5 is a flow chart showing a product manufacturing process of thecomprehensive system of FIG. 1.

FIG. 6 is a flow chart showing a product marketing process of thecomprehensive system of FIG. 1.

FIG. 7 is a flow chart showing a product sales process of thecomprehensive system of FIG. 1.

FIG. 8 is a flow chart showing a product installation process of thecomprehensive system of FIG. 1.

FIG. 9 is a flow chart showing a product registration process of thecomprehensive system of FIG. 1.

FIG. 10 is a flow chart showing a product usage process of thecomprehensive system of FIG. 1.

FIG. 11 is a flow chart showing a product operation process incorporatedin the product usage process of FIG. 10.

FIG. 12 is a flow chart showing a process of making user modificationsto a product in the comprehensive system of FIG. 1.

FIG. 13 is a flow chart showing a product decommissioning process in thecomprehensive system of FIG. 1.

FIG. 14 is a flow chart showing a product service process of thecomprehensive system of FIG. 1.

FIG. 15 is a flow chart showing an active diagnosis process in theproduct service process of FIG. 14.

FIG. 16 is a flow chart showing a PCB failure diagnosis process in theactive diagnosis process of FIG. 15.

FIG. 17 is a flow chart showing a process for developing a list ofcomponents in the PCB failure diagnosis process of FIG. 16.

FIG. 18 is a flow chart showing a software validation process in the PCBfailure diagnosis process of FIG. 16.

FIG. 19 is a flow chart showing a PCB outputs test process in the PCBfailure diagnosis process of FIG. 16.

FIG. 20 is a flow chart showing a PCB inputs test process in the PCBfailure diagnosis process of FIG. 16.

FIG. 21 is a flow chart showing a device failure test process in theactive diagnosis process of FIG. 15.

FIG. 22 is a flow chart showing an appliance output device failures testprocess in the device failure test process of FIG. 21.

FIG. 23 is a flow chart showing an appliance input device failures testprocess in the device failure test process of FIG. 21.

FIG. 24 is a flow chart showing an automated test process in the activediagnosis process of FIG. 15.

FIG. 25 is a flow chart showing an ad hoc test process in the activediagnosis process of FIG. 15.

FIG. 26 is a flow chart showing an operator error test process in theactive diagnosis process of FIG. 15.

FIG. 27 is a flow chart showing a network enabling process in theproduct service process of FIG. 14.

DESCRIPTION OF EMBODIMENTS OF THE INVENTION

FIGS. 1 and 1A shows a comprehensive system for managing a productaccording to the invention. The system includes a product process 10 atone level, system tools 20 that interact with the product process 10,and a data warehouse 30 that interacts with both the product process 10and the system tools 20. It is to be understood that an exemplaryproduct to which the product process 10 is applicable is any type ofproduct that is usable by a consumer, such as a tool, an appliance, asoftware application, or a personal service. While one or moreembodiments may be described in terms of a home appliance such as awashing machine or an oven, the invention is not so limited. Moreover,it is further to be understood that while all or portions of the systemand processes hereinafter described may be performed automatically,e.g., by a computer or a computer network, they are not so limited. Inany given application it may be cost effective for one or more portionsof the system according to the invention to be performed manually.

It may be helpful to envision the system tools 20 as overlaying both theproduct process 10 and the data warehouse 30. The system tools 20include a configuration editor 22, a test editor 24, and a componenteditor 26. It will be understood that any given product will compriseone or more components, the total of which comprises a productconfiguration. The configuration editor 22 modifies or develops theconfiguration of the product. The components editor 26 modifies ordevelops a single component. The test editor 24 enables a testableoperation of a product configuration or component. Any one of or all ofthe configuration editor 22, the test editor 24, or the componentseditor 26 can engage any point of the product process 10 and/or the datawarehouse 30 at any given time. While many of the functions of thesystem tools can be done by humans, it is within the scope of theinvention for these editors to be enabled or facilitated by software.After all, capturing data for an effectively useable database such asthe data warehouse 30 is accomplished best by a computer network.

The data warehouse 30 is one or more relational databases containingcomprehensive information about one or more products. For example thedatabase 20000 can be a list of products to which the product process 10is applicable. Similarly the database 21000 is conceived to be acomprehensive array of product configurations, each product having oneor more configurations. And database 19000 contains a catalog ofcomponents making up the product configurations of database 21000. Thedata warehouse 30 can also contain a list of sources 19500 for thecomponents in the catalog. Components in appliance products, forexample, will include such components and accessories as clocks, cookingaids, sensors, software, and the like as disclosed in internationalapplication entitled COMPONENTS AND ACCESSORIES FOR A COMMUNICATINGAPPLIANCE, filed on Jun. 9, 2006 and contemporaneously with the currentapplication, the entire disclosure of which is incorporated herein byreference. Components can also include such things as test protocols,specialized knowledge, user instructions, etc.

Each product in the product database 20000 will preferably be linked toa mini-warehouse 32 of data about factory tests and performance 18000,customer field tests and performance 17000, and laboratory tests andperformance 16000. Each of these tests will be used to establish adatabase of performance benchmarks 12000. And the performance benchmarkdata 12000 will be related to a separate database of failure data 13000.As well, performance benchmarks 12000 will be linked to sales data 14000which in turn is linked to consumer usage data 11000, and sales floordata 15000 (consumer feedback during the course of the sale). Thislinking enables a correlation between sales and performance benchmarks.In turn, consumer usage data 10000 is affected by a consumer profiles23000 and market segmentation data 22000. Consumer profile data 23000may be obtained, for example, from a product registration process.Market segmentation data 22000 relates to identifiable segments of knownmarkets for the product. For example in the home appliance industry,consumers are sometimes classified into identifiable groups with similarcharacteristics such as “soccer moms”, or “home enthusiasts.”

Process adherence 30000 and data includes information on how well datafrom the data warehouse 30 is propagated and available to variousresources of performing the product process 10. Return on investment(“ROI”) 31000 data provides valuable information on the impact ofreusable components on cost and the availability of resources

Effective communication between the data warehouse 30 and variousaspects of the product process 10 can be accomplished by employing asoftware architecture that enables facile communication between internalcomponents of a product and external components, system tools 10,resources, and the data warehouse 30. The software architecture can beimplemented on and communicate over an internal communications networkin the product. One example of a communications network used within anappliance product is the WIDE network protocol, created by Whirlpool,Inc., the assignee of the present patent application.

Another example of software architecture that can facilitatecommunication between the internal components of a product and 1) otherinternal components, 2) external components, 3) external components inthat product or other products, or 4) other resources external to theproduct such as the data warehouse 30 is disclosed in InternationalApplication entitled SOFTWARE ARCHITECTURE SYSTEM AND METHOD FORCOMMUNICATION WITH, AND MANAGEMENT OF, AT LEAST ONE COMPONENT WITHIN AHOUSEHOLD APPLIANCE, filed Jun. 8, 2006, which claims priority on U.S.Patent Application No. 60/595,148, filed Jun. 9, 2005, both of which areincorporated by reference. All of the methods and processes described inthis application can be facilitated by the software and networkstructures disclosed in either of these applications.

Turning now to the product process 10 in the system according to theinvention in FIG. 1, a normal starting point in the lifespan of aproduct is a product planning process 1000. The product planning process1000 normally results in a product configuration 1800. It also mayresult in enough conceptual information to be sent to an IntellectualProperty (“IP”) management process 1500 where steps can be taken tocommence protection of a new idea. The product configuration 1800 isthen normally sent to a product engineering process 2000. Out of theproduct engineering process 2000, the product is normally sent toproduct and concept testing 3000. If the product survives product andconcept testing, it is then sent to a product manufacturing process. Atsome point simultaneously with this path, a product marketing process5000 is invoked. It will be apparent by the dotted lines amongst thesevarious processes that a product need not sequentially follow theaforementioned processes, but can be fed forward at any point in theproduct process 10 to another point in the product process. For example,a product configuration at 1800 can be disclosed at a trade show as partof the product marketing process 5000 before it is engineered, tested,or manufactured. Similarly, prototypes out of product and concepttesting can be displayed or marketed in the product marketing process5000 to create news or preliminary demand for the product. Likewise, inany point in the path, elements of the product can be sent to the IPmanagement process 1500.

Eventually, if the product survives to the point of being manufacturedin the product manufacturing process 4000, it will enter a product salesprocess 6000. The product sales process 6000 will ordinarily invoke aproduct installation process 6500 and a product registration process7000. These processes may be accomplished by the end user or consumersuch as, for example, in the case of self-installed software or a selfinstalled product such as a home appliance. These processes may also beaccomplished by professional installers.

Normally a product will go through a product usage process 8000, duringwhich the user may occasionally change the product by a usermodification process 9000. Eventually, the product may require some sortof servicing in which case a product service of process 10000 isinvoked. And, at the end of its useful life, the product in itsentirety, or one or more components of the product will bede-commissioned, either voluntarily by the user or involuntarily if theproduct irretrievably fails.

The product planning process 1000 is more fully shown in FIG. 2. It isrecognized from FIG. 1 that various inputs are provided in the productplanning process 1000, e.g., data from product marketing, product usage,product service, and product and concept testing. Whatever the input,the product planning process 1000 follows 1 or 2 paths, individually orsimultaneously. One path contemplates the adoption of proposed newcomponent 1010, which normally go through a product and concept testingprocess 3000. A decision is made at 1015 whether or not to include aproposed new component in the product. If so, then the new component isadded to the product configuration 1800, updating the component catalog19000 in the data warehouse 30. It will be understood that this entireprocess may be conducted virtually by computer, for example.

If a proposed new component is not to be included in the product, thenthe process returns to the start where it continues on the second pathwith known components 1060. Here, relevant information is retrieved fromthe component catalog 19000 and a decision is made at 1063 about whatcomponents to keep. The keep decision 1063 is illumined by additionaldata on consumer usage 11000 and sales 14000 from the data warehouse 30.A decision to keep components results in a number of planned components1065. Typically, a decision will be made at 1067 of whether or not tomodify one or more planned components. The modification decision 1067 isillumined by additional data on performance benchmarks 12000, which mayor may not be modified by failure data 13000. Any design modifications1070 resulting from an affirmative modification decision are added tothe component catalog 19000, and to the product configuration 1800.Typically, the new product configuration 1800 will be added to theproduct configuration database 21000, and may or may not invoke the IPmanagement process 1500. A product successfully exiting the productplanning process will normally go to the product engineering process2000.

FIG. 3 shows the product engineering process 2000, which starts with theproduct configuration 1800 and whatever inputs are provided fromupstream in the product process 10. The system does a lookup in thecomponent catalog 19000 to determine if new components are needed at2020 to meet the product configuration 1800. The system will also obtaindata from the supply chain 32000 and sources in order to determinewhether to build, buy, or outsource a particular component. If no newcomponents are needed then the components are configured at 2200 to theproduct configuration 1800. For example, components may be adapted tofit specific called or defined parameters in the product configuration1800. At system integration 2210, the configured components areassembled into a prototype, and all user interaction component 2215 isassessed. For example, in a home appliance, the process will considerhow a human interacts with the product with due regard forergonometrics. What choices does the user have? Will the user interactwith buttons, voice commands, dials, text screens, keyboard or the like?What options are available for wrong choices?

Eventually, prototypes and the product engineering process 2000 will besubmitted to system tests at 2260, typically in a laboratory, loggingany data for the tests at 2245, and further populating the lab test andperformance database 16000. The system then compares the prototyperesults at 2270 to the product configuration 1800 and, decides at 2275whether modifications are needed. If yes, the system incorporates designchanges at 2290 and returns to configure the components of 2200. If nochanges are needed then the product is forwarded, normally to productand concept testing 3000. The IP management process 1500 will be startedif not previously invoked, or updated. It will be understood that muchof the product engineering process 2000 can be done either virtually bycomputer or physically by real-world prototypes.

A product and concept testing process 3000 according to the invention isshown in FIG. 4. It is contemplated that this process will apply to aspecific product and ultimately provide some business model predictionwith respect to that product. The process starts with a component orproduct configuration at 1020. Cost data can be outputted from thecomponents or product configuration, and is variable depending upon thenumber of factors that can be extracted from the data warehouse 30. Thecomponents and product configuration is subjected to an appropriate testretrieved from the lab test and performance database 16000. This testwill output data concerning reliability, and ideally will validate thetest results.

Further testing at 1025 can include employee field testing (EFT) orcustomer field testing (CUFT) of prototypes. Such testing will providemore data for the CUFT test and performance database 17000, which willenhance information about reliability. The tests can also provide moreinformation about consumer usage 11000 that will enable some outputsabout consumer benefits, and volume projections. As well, these testsmay provide data about the manufacturability and capital requirementsfor the product.

Yet further testing at 1030 can include a limited manufacturing buildthat will provide information on factory test and performance 18000.Finally, a limited production launch in a selected market area canprovide sales floor data 15000, from which the system can gleaninformation on purchaser intent and pricing power. This, in turn, canvalidate information on volume projections. With a proposed componentintegration schedule at 1050, the system can generate a business modelfor the product, giving managers a valuable tool to make decisions aboutthe product. It will be understood that product and concept testing 3000can be done virtually by computer modeling, or in the real-world withphysical prototypes and manufacturing, or a combination of both.

A product manufacturing process 4000 according to the invention is shownin FIG. 5. It typically starts with predetermined inputs as shown inFIG. 1. Although aspects of the process can easily be adapted to aservice product, this process is more applicable to a physical product.For example, consider a networkable home appliance moving down assemblyline. The product is assembled at 4010 to a point where some functionscan be enabled. One of those functions is communication, which isenabled at 4012. A computer remote from the assembly line can attemptcommunication with the appliance and make adjustments necessary toassign a unique product identification at 4015. Product tests can beretrieved at 4020 from the data warehouse 30, including appropriatetests for quality control. As our home appliance moves down the line aremote test computer can identify the appliance using the pre-assignedproduct identification and gain access to the internal network of theappliance. The remote test computer can virtually run the appliancethrough its cycles according to the product configuration 1800, gaincomplete functionality of the appliance, and test it at 4025 accordingto the protocols retrieved from the data warehouse 30. The system canadd the product, the product configuration, and the tested components tothe respective databases 20000, 21000, and 19000, respectively, whichhad previously been enhanced by the product engineering process 2000,for example. Results of the tests will be sent to the factory test ofperformance database 18000.

A product marketing process 5000 according to the invention is shown inFIG. 6. Product marketing can start with the launch of a publicrelations cadence, with nothing more than concepts at 5010 to createbuzz and stimulate demand, or to announce coming new product features at5020, or simultaneously with the launch of a product at 5015. Timing canbe done relative to a product launch such as pre-launch public-relationsat 5025, actual product launch public-relations at 5030, and post launchpublic-relations at 5040.

Typical public-relations types at 5050 include pilots that would beconsidered limited deployment of production products, partnerships suchas a limited deployment with the particular partnering company,announcement of new features and accessories, special orders in specialmarkets, and trade shows and general media. Public-relations can becentered around certain themes. For example in the home applianceindustry, public relations may be centered around a green theme, i.e.,how environmentally friendly the appliance is. Other exemplary themesinclude halo (“the Angel affect”), high-tech, soccer moms, new growth(directed to financiers as an innovative company), and gadgets. Thesystem will preferably include measurable outcomes in the productmarketing process for core sales, company image, and stock price for apublicly traded company.

A product sales process 6000 according to the invention is shown in FIG.7. The product sales process 6000 starts with the consumer nearing theproduct at 6010. It is important to remember that the inventioncontemplates this nearing step occurring in the real world as a consumerapproaches or passes by a product on display, and also in the virtualworld as a consumer uses a mouse to click on or hover over an image in aweb page. The product can be configured to solicit the consumer at 6020directly with text, video, voice or some other notification, or,alternatively, the product can be configured to notify an agent tosolicit the consumer, e.g., a salesperson. At 6030, either the productitself, or the agent interacts with the consumer and gains informationthat can be fed to the data warehouse 30, and more particularly,consumer profiles 23000 and market segmentation 22000. As well, theinteraction at 6030 can enhance the sales floor data 15000.

In response to that interaction or as a result of the interaction, theproduct or the agent at 6040 can suggest to the consumer anotherproduct. As well, the consumer can interact with the product and/or theagent to learn about the product at 6050. At some point a decision canbe presented to the consumer at 6055 whether or not to purchase theproduct. If the consumer decides not to purchase the product, continuedinteraction can occur or process can terminate. On the other hand, ifthe consumer decides to purchase the product, the consumer can befurther presented at 6060 with the opportunity to customize andaccessorize the product and purchase ancillary products. For examplewith a home networkable appliance, the consumer can have the option topurchase extended warranties, passive diagnostic capability, andadditional software enhancements. The purchase is transacted at 6070, arecord of which is sent to the sales database 14000 and the process canmove to installation.

A product installation process 6500 according to the invention is shownin FIG. 8. The product installation process 6500 starts with appropriateinputs (see FIG. 1.) and continues with setting the product in place at6510. Product hookups may be required at 6520, as in the case of a homeappliance. If not previously conducted in the sales process, the productcan be registered at 7000. The manufacturer can make registration acondition to enable usage of the product at 6530, or, alternativelypermit the consumer to bypass registration and provide periodicreminders at 6535. It is contemplated that enablement, particularly ofan appliance, can include various modes, any one or all of which can beenabled depending on what was purchased. For example consider anetworkable washing machine appliance. Installation can include enablingan automated use and care guide at 6540, which, on activation duringusage, can automatically provide instruction to the consumer on use ofthe appliance. When the consumer pushes a particular button on thewashing machine, the appliance can issue a voice suggestion or providetext display that only certain detergents will work with the particularfeature selected. Installation can also include enabling passivediagnostics at 6550. Here, the appliance can continuously monitor theperformance of all components of the washing machine and advise theconsumer (again by voice or by text) that a particular component isabout to fail and needs to be replaced. Installation can also includeenabling information mediation at 6560 where the consumer is presentedwith the opportunity to share usage data of the washing machine with themanufacturer or with a third-party. Installation can also includeenabling an enhancement guide where the consumer can be presented withreminders of available enhancements, based on automatically observedinteractions between the consumer and the washing machine. Installationcan also include enabling enhancements to the networkability of thewashing machine. For example, the unique identifier for the washingmachine can automatically be added to the list of recognized devices inother networked appliances. Moreover, the washing machine can beconfigured to automatically acquire identifiers in later acquiredappliances and coordinate automatically updated ownership informationwith the data warehouse 30 for previously registered owners.

A product registration process 7000 according to the invention is shownin FIG. 9 and starts by invoking the process at 7010. As previouslyindicated, this can occur in the product sales process 6000, in theproduct installation process 6500, separately or sometime during theproduct usage process 8000. As well, product registration can occur atthe user modification process 9000, or even during product service 10000(see FIG. 1). Product registration can be invoked at the consumercommand, or the command of the sales agent, or automatically withenablement of the product. Once invoked, a product identification isuploaded at 7020 and any appropriate customer identification isdownloaded. That information can be gleaned from other products or homedevices at 7025 or from sales data 14000. In this embodiment, theproduct has a GPS installed to automatically record an address where theproduct is installed. Continuous transmission of the address to the datawarehouse 30 can enable theft control if the product is portable andsubject to theft. For example, a portable microwave moved from itsregistered address can trigger a notification to the consumer (e.g. bycell phone or email) that the appliance has been moved. Moreover,continuous transmission can track the location of the microwave duringits movement.

The consumer is preferably given the opportunity to confirm and correctretrieved data at 7030. Once confirmed, the product can be enabled forusage at 7060 (if registration is a condition for enablement), and thewarranty can be activated at 7050. Preferably, warranty and servicedatabases at the data warehouse 30 will be updated at 7040. In the caseof a product that may be part of an energy management arrangement(discussed below), notification can automatically be sent to anappropriate energy utility at 7200 and this consumer can be enrolled ina resource management program 7210.

A product usage process 8000 according to the invention is shown in FIG.10. Product usage starts with the product operation 8020 according tothe invention and can present the user with some of the optionsavailable during product installation 6500. For example, the consumercan be presented with a decision at 8015 to share usage data of theproduct with the manufacturer or with a third-party. If the decision isaffirmative, the product is configured into an information mediationsystem at 8010 and that information is transmitted to the appropriatedatabase at the data warehouse 30. Similarly, the consumer can bepresented with the decision at 8025 and enable an automated use and careguide which, on activation during usage at 8030, can automaticallyprovide instruction to the consumer on use of the product. As well, atany point during product operation, enhancements can be suggested to theconsumer or by the consumer at 8030. If a particular feature is needed,and enhancements process 9000 is invoked.

The product operation process 8020 according to the invention is shownin FIG. 11. Here, product operation commences with the task input 111.The task input 111 can be a sub process unto itself, and may includesomething as simple as a button push, a switch operation, a text input,or voice command. It can automatically be invoked by a software commandor the automatic consequence of a diagnosed problem. Normally the taskinput 111 will result in some routing decision 112 where the productwill be called upon to resolve the task input directly, through someexternal agent or client, or through human intervention. Preferably,some progress indication 113 can be provided to the consumer from therouting decision 112. For example, in the cooking appliance such as anoven, the status of the oven can be updated such as a countdown timerstarting before cooking actually begins.

If appropriate enhancements have been enabled on the product, adiagnosis sub process 114 can be invoked to provide some contextualresponse to the input command and routing decision, or refine thecommand and routing based on the context. For example, a washing machinecan be programmed to, accept commands only from an authorized user. Thediagnosis sub process 114 can interrogate the entry of the task input at111 to ensure that the command came from an authorized user. Thediagnosis sub process can also identify a problem with the task inputand provide an alternative solution decision 115. For example, say theconsumer entered a command into the washing machine for a small wash,but overloaded the washing machine with clothes. The washing machine candetect the overload, determined an appropriate solution and suggests asolution to the consumer (remove some clothes), or even automaticallyoverride the task input for a small wash with a command for a largewash, notifying and updating the user with the status at 113. Thesolution is redefined and executed at 116 and audited at 117. Preferablythe data is logged and up loaded to the data warehouse 30, and the useris updated with the actual result of the task input. If the resultdiverges from the original task input, the product can provide somecontext or reason for the divergence, and suggest tips for avoidingdivergence in the future.

If a problem is detected, the user is preferably presented with aninquiry at 118 about whether or not the problem was solved. If not, therouting decision 112 is reevaluated, and if so, the system is reset forentry of a new task input at 111. It is to be remembered that thediagnosis sub process 114 does not only refer to diagnosing problems,but more broadly the diagnosing of alternative commands. For example,the process could result in a recommendation to the user of a differentcommand, automatic implementation of a different command, an errormessage, with or without implementation, a helpful hint or warning, andoffer to purchase a new product or enhancement, or an offer toparticipate in the aforementioned information mediation system or energymanagement system. The diagnosis can be based on user preferences orexperience from previous or continued audits, energy consumption,resource availability, timing based on noise and vibration, timing basedon use or demand, sensors and other inputs, availability of cycles, andinformation exchanged on the network with other products.

The process of FIG. 11 can be used as a template to implement any of theprocesses disclosed herein. That is, whatever the process or processstep might be, it can be resolved to or thought of as a task input. Thetask input is then routed for decision, especially whether the task canbe resolved locally, by human intervention, or by an external agent. Inthe case of the product, the product will look for a local solutionwithin the product, to the user, or to a source exteriorly of theproduct. In the diagnosis step, the task will be analyzed orinterrogated to ensure the validity of the command. If need be the taskis modified, alternatives can be suggested, or a new solution to thetask can be proposed. The resulting solution to the task is thenexecuted and subject to an audit. As one can readily see, when theprocess of FIG. 11 is applied to a process, it provides for: theinspection of the process and all of its steps; a determination of wherethe steps are to be completed or where information to complete the stepsis to be drawn, confirmation of the appropriateness of the steps,modifications to the steps, or alternatives to the steps; theimplementation of the steps; and the auditing of the solution. Theresult and related information is then saved to the Data Warehouse 30for subsequent use. The process of FIG. 11 is repeated until the problemis solved. In this way the process can self-improve. The template can beapplied to the process as whole, a subset of the steps, on astep-by-step basis, or a combination of them all.

A process for user modifications 9000 according to the invention isshown in FIG. 12. This process contemplates enabling the user to add orremove components in the product. Modifications to be added might havebeen purchased by the consumer in the sales process 6000 or initiated inthe product usage process 8000. The process commences with theinstallation of the modification at 9010. It will be understood that inthis context, installation may also include removal of a component. Theproduct or a system of communications in which the product is networkedmay have to suspend normal operation at 9010 during installation, andthe modification joins the system where the system recognizes themodification. Simultaneously, product registration in accord with theproduct registration process 7000 can occur. It may be necessary tovalidate the modification at 9025 prior to configuration. Validation caninclude confirmation that the modification is appropriate, authorized,registered, and operable. If not validated, a notification at 9027 canupdate the consumer usage data base 11000 at the data warehouse 30. Ifvalidated, the modification either can configure itself or allow thesystem to configure itself at 9030, or the system adapts to themodification and allows the modification to configure the system at9040, or some combination of both. Preferably, the data warehouse 30 isupdated with consumer usage 11000, service and warranty data 33000, andproduct registration data 34000. Once configured, the product resumesnormal operation at 9050 and the system interacts with the modificationat 9060.

An example of a product enhancement is the registration of the productwith a resource provider, such as an electrical utility. The user canregister online with the resource provider and contract for purchasingelectricity at predetermined rates, which can include reduced rates fornon-peak usage. The user could also contract for electrical supply to beterminated or reduced by the resource provider based on system demands.The user could also contract for the supply of energy based on acommodities market price approach, the price of which could be set byonline auctions.

A product decommissioning process 9500 according to the invention isshown in FIG. 13. At some point the useful life of the product orcomponent of the product will come to an end. This begins the productdecommissioning process 9500. The consumer may decide to remove theproduct from use at 9600. Preferably, the consumer need only inform oneof the network products of the decommissioning of an identified productat 9610. The consumer can be prompted to power down the product orremove communication and 9620. In another aspect of this process,products on the network may sense at 9510 that a product is missing fromits registry of connected devices, also known as a “know about list.”The networked system makes a determination at 9520 of the productidentified to be missing. An inquiry at 9525 to the consumer verifieswhether the removal is temporary or permanent. If permanent, thenetworked system removes the product from the know about list at 9530,prompts the user with recycle information and 9540 or suggestedassistance for de-installation of the product, and may suggest areplacement or provide for automated ordering and 9550. Preferably, thewarranty and service databases at the data warehouse 30 are updated at7040.

A product service process 10000 according to the invention is shown inFIG. 14. The product or service process 10000 provides one of the mostconvenient benefits of the comprehensive system of product managementaccording to the invention. The product service process commences withan inquiry at 12 of whether or not passive diagnosis in the product isenabled. If not enabled, the consumer is presented with another inquiryat 13 with the opportunity to install a passive diagnosis component. Ifthe answer to that inquiry is yes, passive diagnosis component isinstalled and commenced. If the answer that inquiry is no, the user isprompted with another inquiry at 22 about whether a problem is observed.If no problem is observed, the system restores to the product servicestart. If a problem is observed, then the user is presented with anotherinquiry at 24 about whether the product is network ready. If not, theuser is prompted at 25 to enable the network using the network enablingmethod at 26. If the user chooses not to enable the network, the usercan be presented with a use and care guide, warranty information, orother service information at 27.

Once the network is enabled, the system invokes one of three activediagnosis processes, as preferred by the consumer. The active diagnosisprocesses include do-it-yourself (DIY) service at 30, remote service at40, or local service at 50. The consumer can be presented with apreference list, menu, or sequential inquiries. These choices aredirected to who is going to conduct the active diagnosis process at 60.It is contemplated that a product capable of being networked will haveone or more printed circuit boards (PCB's) and input/output (10) ports.Service architectures 32 will be predetermined for the product and willcomprise ways of communicating problems in getting solutions during thediagnosis process. Exemplary service architectures include (1)integrated audible codes on a PCB in the product that can becommunicated to a service center by telephone (wireless or land line),(2) integrated audible codes on multiple PCBs in the product networkedtogether that can be communicated to a service center by telephone(wireless or land line), (3) distributed audible codes on multiple PCBsin the product networked together that that can be communicated to aservice center by telephone (wireless or land line), (4) externalaudible signals wirelessly connected to one or more PCBs that can becommunicated to a service center by telephone (wireless or land line),(5) a service computer connected by cable to one or more PCBs in theproduct by way of an IO port, (6) a service computer connectedwirelessly to one or more PCBs in the product by way of an 10 port, (7)a remote data connection by Internet or phone modem between a servicecenter and an JO port on the product, (8) a remote data connection byUSB, flash drives and automated keys, conveyed by courier, (9) errorcodes displayed on board the product, (10) error codes displayed onboard a remote product networked with the diagnosed product, and (11)the traditional backend technician communicating with consumer orservice tech.

The active diagnosis process 60 is operated as described below, and theconsumer is then presented with an inquiry at 62 of whether or not thesolution was identified. If not, the active diagnosis process isrecommenced. If so, the system can identify parts or replacements neededat 70, automatically order parts at 72, order replacement and 74,received the parts or replacement at 73, and execute a solution at 74.

If the passive diagnosis process operates at 14, it faces an inquiry at20 of whether not problem is detected. If the problem is not detectedthe consumer is presented with the inquiry 22 about observation of theproblem. On the other hand if the passive diagnosis process detects aproblem, the system notifies the consumer at 15 and faces an inquiry at28 of whether or not a solution as identified. If the solution isautomatically identified, the system's proceeds to ordering parts orreplacements at 70. If the solution is not identified a 28, the activediagnosis process is invoked.

Upon execution of the solution at 74 the system then queries at 75whether or not a warranty is in place, gathering pertinent terminationfrom the data warehouse 30. If a warranty is in place, the warrantorbears responsibility for the cost of the solution. If no warranty is inplace, the user bears responsibility for the cost of the solution.

The active diagnosis process 60 is shown in FIG. 15 with the sequentialtests in the process shown in FIGS. 16 through 26. The active diagnosisprocess 60 commences with establishing communication at 601 between atest observer and the product. Also, at 603, the data warehouse 30 isaccessed. The test observer at 602 acquires the product's or component'sidentification and, at 604, based on that identification retrievesappropriate software, data, documents, applications, and components andproduct information from the data warehouse 30. Depending on the scopeof a failure, for example as in a total failure mode, the test observermay be prompted to change the service architecture 32 for the diagnosis.

The first test in the active diagnosis process is the PCB failures testat 630. The PCB failures diagnosis is shown in FIG. 16, and commenceswith the test observer developing a list of components to operate on.Looking now to FIG. 17, the list of components 632 is obtained byexecuting a discovery command at 634 to retrieve appropriate data on thecomponents from the data warehouse 30 or from stored data in theproduct. Appropriate component identification is stored at 636 in anappropriate memory location. Returning to FIG. 16, the PCB failurediagnosis proceeds to an inquiry at 635 to determine if all componentsin the list have been tested. If not, then the system proceeds to asoftware validation at 640.

The software validation process 640 is shown in FIG. 18. The processcommences at 641 with a check for any updated software versionsavailable for the PCB component or the product. The system comparesproduct and components version information at 604 with updated productconfiguration data 21000 from the data warehouse 30, and answers aninquiry at 642 whether an update is required. If an update is required,the update is performed at 645. If an update is not required, the systemis presented with an inquiry at 643 about service bulletins. If servicebulletins are available and needed, appropriate action is taken at 646to obtain them. If no further service bulletins are available or needed,the system then conducts a cyclical redundancy check (CRC) at 644 andcompares the expected CRC for the product to the actual CRC. An inquiryat 647 determines if there is a mismatch in the compares. If there is amismatch, then the PCB component is determined to have failed and thePCB failure diagnosis process returns a failure. If there is nomismatch, then the PCB failure diagnosis process returns a pass andproceeds to a PCB outputs test 650 (see FIG. 16).

The PCB outputs test process 650 is shown in FIGS. 19-19B. The processcommences with a reconfiguration at 652 of the PCB connections accordingto FIGS. 19A and 19B. The wiring harness 104 between the PCB 100 and thedevices 102 that are controlled by the PCB as shown in FIG. 19A isdisconnected and reconnected to a test fixture 101, operably connectedto the test observer at 105 as shown in FIG. 19B. Typically, thisreconnection will be done manually, but it is within the scope of theinvention for the reconnection and reconfiguration to be doneelectronically by way of a switch, or electronically for example. Theconnection between the test fixture 101 and the test observer 105 can bewireless or remote, depending upon the service architecture 32 applied.The test fixture 101 can be little more than an IO port on the product.With access to the product configuration data 21000 and of the productor complement version information 604, the test observer is configuredat 653. At 654 the test observer energizes each output, individually andsequentially, sensing the corresponding power output at 656 andcomparing the result to the expected results based on information in theproduct configuration data 21000. Each test results in an inquiry at 658of whether or not a mismatch has been detected. If there is a mismatch,then the PCB component is determined to have failed and the PCB failurediagnosis process returns a failure. If a mismatch is not detected, thenthe system inquiries whether or not all outputs have been tested at 659.If all outputs have not been tested, the system loops to the nextoutput. If there is no mismatch on any output, then the PCB failurediagnosis process returns a pass and proceeds to a PCB inputs test 660(see FIG. 16).

The PCB inputs test process 660 is shown in FIGS. 20-20B. The processcommences with a reconfiguration at 662 of the PCB connections accordingto FIGS. 20A and 20B. The wiring harness 104 between the PCB 100 and thedevices 102 that are controlled by the PCB as shown in FIG. 20A isdisconnected and reconnected to a test fixture 101, operably connectedto the test observer at 105 as shown in FIG. 20B. Typically, thisreconnection will be done manually, but it is within the scope of theinvention for the reconnection and reconfiguration to be doneelectronically by way of a switch, or electronically for example. Theconnection between the test fixture 101 and the test observer 105 can bewireless or remote, depending upon the service architecture 32 applied.The test fixture 101 can be little more than an IO port on the product.With access to the product configuration data 21000 and of the productor component version information 604, the test observer is configured at663. In addition, at 663A, the test observer is also configured toaccess specific memory locations on the PCB. The data acquisition enginedisclosed in either international application entitled SOFTWAREARCHITECTURE SYSTEM AND METHOD FOR COMMUNICATION WITH, AND MANAGEMENTOF, AT LEAST ONE COMPONENT WITHIN A HOUSEHOLD APPLIANCE, filed Jun. 8,2006, which claims priority on U.S. Patent Application No. 60/595,148,filed Jun. 9, 2005, is particularly adapted to enable such aconfiguration in the test observer. At 664, the test observer sets eachinput according to the product configuration 21000 as if the productwere operating, attempting to drive the PCB to an expected result.Consequently, at 666 the test observer measures a value at acorresponding memory location and compares the measured value to theexpected value. Each test results an inquiry at 668 of whether or not amismatch has been detected. If there is a mismatch, then the PCBcomponent is determined to have failed and the PCB failure diagnosisprocess returns a failure. If a mismatch is not detected, then thesystem inquiries whether or not all inputs have been tested at 669. Ifall inputs have not been tested, the system loops to the next input. Ifthere is no mismatch on any input, then the PCB failure diagnosisprocess returns a pass and proceeds to a device failure test 670 (seeFIG. 15).

The second test in the active diagnosis process is the device failurestest process 670. The device failures diagnosis is shown in FIG. 21, andcommences with the test observer developing a list of components tooperate on. See FIG. 17. The device failures diagnosis proceeds to aninquiry at 671 to determine if all components in the list have beentested. If not, then the system proceeds to a product output devicefailures test at 670A.

The product output device failures diagnosis is shown in FIG. 22. Itcommences at 672 with an inquiry about whether or not power sensing isenabled. In order for this diagnosis to be effective, the system mustprovide some way of sensing power such as by way of current, eitherindividually or at a common line. Appropriate information on powersensing may be obtained from the product configuration data 21000 ordata warehouse 30. If power sensing is not enabled, the power sensingapparatus must be configured at 678. If power sensing is enabled, thatthe second inquiry is presented at 673 to determine whether or notcomponent self test is enabled. This inquiry answers the question ofwhether or not the expected power curve is present for comparison orwhether it needs to be obtained. If the component self test is notenabled, the test observer must be configured at 678 with theappropriate device and device power consumption profiles at 673,obtained from the product configuration data 21000. Once everything isconfigured, the product output device failures diagnosis proceeds to aninquiry at 674 to determine if all devices in the list have been tested.If not then the next device output is set to on at 675 and the actualpower consumption profile is compared at 676 to the expected powerconsumption profile. If there is a mismatch, then the PCB component isdetermined to have failed and the PCB failure diagnosis process returnsa failure. (See FIG. 15) If none of the devices show a mismatch, and theprocess returns to the product input device failures test at 670B (seeFIG. 21).

The product input device failures diagnosis is shown in FIG. 23. Itcommences at 700 with an inquiry about whether or not component selftest is enabled. If not, then the test observer and the PCB areconfigured at 702 with appropriate plant models obtained at 704 from theproduct configuration database 21000. Plant models drive the input to anexpected result or state at the output. The system determines andconfigures appropriate data collection at 708 and sets an output ormemory pattern according to the input device plant model definitionobtained from the plant model at 712. The process then determines at 713if virtual key presses or some other virtual input is required in orderto drive the input to the expected result. If so then virtual commandsare set at 714 and if not, in inquiry presented at 715 of whether userintervention is required. An example of user intervention in a washingmachine might be to manually insert an unbalanced load. If userintervention is required, then the user is prompted at 716 to initiatean action in the system inquiries at 717 whether the action has beencompleted. If so, then the input value is compared to the expectedoutput result at 718. If there is a mismatch, then the PCB component isdetermined to have failed and the PCB failure diagnosis process returnsa failure. (See FIG. 15) If the device does not show a mismatch, thenthe process returns to an inquiry at 710 of whether or not all deviceshave been tested. If not, then the next input device is set at 712 andthe test redone. If there is no mismatch on any input device, then thedevice failure diagnosis process returns a pass and proceeds to anautomated test 610 (see FIG. 15).

The automated test process 610 is the third test and is shown in FIG.24. This diagnosis checks for more subtle issues such as environmentalissues, overheating, or types of consumables, and draws more extensivelyon statistical evidence at the data warehouse 30. The automated testdiagnosis is shown in FIG. 24, and commences at 611 with an inquiryabout whether or not the component self test is enabled. If not, thenthe test observer is configured at 612 with system tests macros 613obtained from the product configuration database 21000. The systemdetermines and configures appropriate data collection at 614 andretrieves the macros' expected data patterns at 660. An inquiry at 618asks whether or not all macros have been completed. If not, then theprocess sets outputs and memory values according to the next macrodefinition at 620 and checks the input value against expected results.If there is a mismatch, then the PCB component is determined to havefailed and the PCB active diagnosis process returns a failure. (See FIG.15) If the device does not show a mismatch, the process returns to theinquiry at 618 of whether not all macros have been tested. If there isno mismatch on any macro, then the automated test diagnosis processreturns a pass and proceeds to another test in the active diagnosisprocess (see FIG. 15).

The active diagnosis process contemplates the PCB failures diagnosis 630and the device failure diagnosis of 670 in the automated test diagnosis610 as being conducted sequentially. Two more tests are available in theactive diagnosis process, and ad hoc test 690 and an operator error test720, including initially before the first three, or after.

The ad hoc test 690 is shown in FIG. 25. This test is designed toempower the user with enough information to capture something new in adiagnosis of the product. It commences with the configuration of thetest observer at 692 based on data from the product configurationdatabase 21000. It commences downloading engineering documents at 694,service history of the product, including model and class and 696 and indownloading previous ad hoc transaction logs if any are applicable. At693, the test observer enters a process capture mode and prompts theuser at 695 to capture certain user information. Once all theinformation is in place, the system queries at 698 for additional ideasfor diagnostic tests. At this point the user can select one or more testideas from the download or add new tests to execute. An affirmativeresponse to the inquiry about additional tests to be conducted resultsin another inquiry at 699 about whether or not the test already exists.If so, then the system proceeds to execute the tests at 708. If the testis new, the new test is created at 700, test steps are queried and addedat 702, 704, and the system automatically assigns a globally uniqueidentifier to the test at 706. One or more tests are executed at 708,with captured data resultant and perhaps the test observer's analysis ofthe results. The test is logged 710 and submitted to the data warehouse30. An inquiry 712 determines whether or not the problem has beenidentified and whether or not the ad hoc test is continued or returnedto the active diagnosis process 60.

The operator error test 720 is shown in FIG. 26. This test commenceswith several inquiries designed to determine the level of engagementwith the user. For example an inquiry at 722 determines whether of theproduct is speech enabled, and at 724 whether or not the product is textenabled, and at 725 whether or not the product is video enabled, and at726 whether or not the user desires to purchase a kit to enhance orenable such communication. If so the modifications downloaded at 728,with appropriate data from the product configuration database 21000.Once communication is established, the problem is inputted at 730 and aninquiry at 732 determines if the problem is recognized. If so, thesystem compares user settings and actions in the product to a preferredmodel inquiries a mismatch at 736. If a mismatch exists, the suggestedalternate selection is prompted to the user at 734 whereupon selectionscan be changed at 740 and an inquiry about resolution of the problem at742. If the problem is resolved the transaction is logged at 740 andthat diagnosis is terminated. If the problem is not resolved, a furtherproblem can be inputted or the problem can be re-inputted at 730. Ifthere is no mismatch at 736, the system can prompt some interaction withthe user at 738. Failure of further interaction at 744 will move thesystem toward some help mode at 750. The user can determine at 752 iffurther interaction with the user interface is desired. If not thetransaction ends and is logged 740. If so, output information isprovided at 754 and an interaction with the user is conducted at 756 andthe problem may or may not be resolved at 758. If the problem is notsolved, the process loops back to step 752. If the problem is resolved,the transaction is logged and control returns to step 720 to resolve anyfurther errors, and, if none, terminated.

Referring again to FIG. 14 and the product service process 10000, thenetwork enabling method 26 is shown in FIG. 27. It commences with aninquiry at 262 about whether a network connection is available. If not,then user is prompted at 264 to purchase or otherwise acquire andinstall, a connection kit. If a network connection is available, or ifthe user has otherwise installed a network connection, the systemqueries at 266 whether or not the network connection is wired orwireless. If wireless, the user is presented with the opportunity at 268to acquire, such as by purchase, a key, a dongle, or other accessory toenable and facilitate the active diagnosis process. Software isinstalled, commissioned and operated with the goal of establishingnetwork communication with minimal crosstalk among possibly conflictingdevices.

Referring again to FIG. 14 and the passive diagnosis process at 14, itwill be understood that the passive diagnosis process will be similar toor the same as the active diagnosis process but configured to runpassively without user or test observer intervention. In such anembodiment, the test observer will be built in to the product, remote orautomatic switching of connections can occur by software command, andthe time to run such an automatic passive diagnosis will normally be atthe time when the product is not in operation.

While the invention has been specifically described in connection withcertain specific embodiments thereof, it is to be understood that thisis by way of illustration and not of limitation, and the scope of theappended claims should be construed as broadly as the prior art willpermit.

1. A comprehensive product management system for a product comprisingone or more components, the system comprising discrete processes forplanning, engineering, testing, producing, selling, using, and servicinga product, a comprehensive relational database containing informationabout the product, performance, sales, consumers, and markets, andsystem tools for operating on the discrete processes, wherein anyprocess automatically interacts with the comprehensive database, andselectively interacts with the system tools.
 2. The system according toclaim 1 and further comprising at least one of the following: productplanning cycle, IP management cycle, product engineering cycle, producttesting cycle, concept testing cycle, product manufacturing cycle,product marketing cycle, product sales cycle, product installationcycle, product registration cycle, product usage cycle, productoperation cycle, product enhancements cycle, product decommissioningcycle, product service cycle, and product diagnostic cycle.
 3. Thesystem according to claim 2, wherein the product diagnostic cyclecomprises at least one of: a PCB failure cycle, sequential componenttest cycle, software validation cycle, PCB output test cycle, PCB inputtest cycle, input device test cycle, output device test cycle, automatedsystem test cycle, ad hoc test cycle, operator error cycle, and userinstruct cycle.
 4. The system according to claim 2, wherein the producttest cycle comprises at least one of: physical prototype test cycle,virtual prototype test cycle, and customer field test cycle.
 5. Thesystem according to claim 2, wherein the product manufacturing cyclecomprises at least one of product identification cycle, productcommunication cycle, and product virtual test cycle.
 6. The systemaccording to claim 2, wherein the product marketing cycle comprises atleast one of product idea cycle, product feature cycle, productpre-launch cycle, product launch cycle, and product post-launch cycle.7. The system according to claim 2, wherein the product sales cyclecomprises at least one of: consumer solicitation cycle, consumerinteraction cycle, consumer feedback cycle, warranty cycle, and productcustomization cycle.
 8. The system according to claim 2, wherein theproduct installation cycle comprises at least one of: resource hookupcycle, product registration cycle, and enable product usage cycle. 9.The system according to claim 2, wherein the product registration cyclecomprises at least one of: product identification cycle, customeridentification cycle, product location cycle, user feedback cycle,warranty activation cycle, and resource registration cycle.
 10. Thesystem according to claim 2, wherein the product operation cyclecomprises at least one of: task input cycle, task decision cycle, taskdiagnosis cycle, task solution cycle, solution execution cycle, andsolution audit cycle.
 11. The system according to claim 2, wherein theproduct enhancements cycle comprises at least one of: modificationinstallation cycle, operation suspension cycle, and productconfiguration cycle.
 12. The system according to claim 2, wherein theproduct de-commissioning cycle comprises at least one of: identificationof de-commissioned product cycle, and product replacement cycle.
 13. Thesystem according to claim 2, where in the product service cyclecomprises at least one of: do it yourself service cycle, remote servicecycle, local service cycle, active diagnosis cycle, and passivediagnosis cycle.
 14. A comprehensive product management system for aproduct comprising one or more components, the system comprising:discrete processes for planning, engineering, testing, producing,selling, using, and servicing a product, a comprehensive relationaldatabase containing information about the product, performance, sales,consumers, and markets, and system tools for operating on the discreteprocesses, wherein any process automatically interacts with thecomprehensive database, and selectively interacts with the system tools.15. The system according to claim 14 wherein at least a first pluralityof the discrete processes provide experiential information to thedatabase relating to plurality of products and at least a secondplurality of discrete processes for a first product accesses informationfrom the database provided by a different one of the discrete processrelating to a second product as a basis for making a control decisionfor the first product.
 16. The system according to claim 14 wherein thesystem tools comprise a configuration editor adapted to configure theproduct, a component editor adapted to configure at least one componentof the product and a test editor adapted to enable a testable operationof at least one of the product and the component.
 17. The systemaccording to claim 14 wherein the database comprises at least onerelational database containing at least one of: a catalogue ofcomponents potentially applicable to the product, performance benchmarkdata, consumer data, and ROI data.
 18. The system according to claim 14wherein the performance benchmark data comprises at least one of:factory test and performance data, consumer field test and performancedata, and laboratory test and performance data.
 19. The system accordingto claim 14 wherein the customer data comprises at least one of:customer usage data, sales floor data, and customer profile data. 20.The system according to claim 14 further comprising at least one of adiscrete processes for marketing, installation, product registration,product usage, user modification and decommissioning.
 21. The systemaccording to claim 14 wherein at least one of the discrete processcomprises the steps of: locally inputting a task, deciding where toroute the decision making from a selection of at least local, user andremote diagnosing the task, selecting a decision, executing thedecision, and auditing the decision.
 22. A comprehensive productmanagement method for a product comprising one or more components, themethod comprising the steps of planning the product while automaticallyinteracting with a comprehensive relational database containinginformation about the product, performance, sales, consumers, andmarkets; engineering the product while automatically interacting withthe database; testing the product while automatically interacting withthe database; producing the product while automatically interacting withthe database; selling the product while automatically interacting withthe database; operating the product while automatically interacting withthe database; and servicing the product while automatically interactingwith the database.
 23. The method according to claim 22 furthercomprising at least one of: marketing the product, while automaticallyinteracting with the database; installing the product, whileautomatically interacting with the database; registering the product,while automatically interacting with the database, operating theproduct, while automatically interacting with the database; modifyingthe product, while automatically interacting with the database; anddecommissioning the product, while automatically interacting with thedatabase.
 24. The method of claim 23 wherein the operating of theproduct comprises at least one of: locally inputting a task, decidingwhere to route the decision making from a selection of at least localdecision making, user decision making and remote decision making,diagnosing the task, selecting a decision, executing the decision, andauditing the decision, wherein remote decision making uses acomprehensive relational database containing information about theproduct, performance, sales, consumers, and markets, and system toolsfor operating on the discrete processes.
 25. A comprehensive productmanagement method for a product comprising one or more components, themethod comprising the steps of locally inputting a task selected from atesting task, an operating task, a servicing task servicing the product,marketing task and installation task, a registering task, a modifyingtask and a decommissioning task, deciding where to route the decisionmaking from a selection of at least local decision making, user decisionmaking and remote decision making, diagnosing the task, selecting adecision, executing the decision, and auditing the decision, whereinremote decision making uses the database and system tools to implementthe diagnosing, selecting and auditing steps.